内存一致性协议

由于 CPU 执行速度很快，而从内存读取数据和向内存写入数据的过程跟 CPU 执行指令的速度比起来慢得多，因此如果任何时候对数据的操作都要通过和内存的交互来进行，会大大降低指令执行的速度。因此在 CPU 里面就有了高速缓存。

当程序在运行过程中，会将运算需要的数据从主存复制一份到 CPU 的高速缓存中，那么 CPU 进行计算时就可以直接从它的高速缓存读取数据和向其中写入数据，当运算结束之后，再将高速缓存中的数据刷新到主存当中。（在多核 CPU 中，每条线程可能运行于不同的 CPU 中，因此每个线程运行时有自己的高速缓存；对单核 CPU 来说，其实也会出现这种问题，只不过是以线程调度的形式来分别执行的。本文我们以多核 CPU 为例）。

可能存在下面一种情况：初始时，两个线程分别读取 c 的值存入各自所在的 CPU 的高速缓存当中，然后线程 A 进行加 1 操作，然后把 c 的最新值 1 写入到内存。此时线程 B 的高速缓存当中 c 的值还是 0，进行加 1 操作之后，c 的值为 1，然后线程 2 把 c 的值写入内存。

为了解决缓存不一致性问题，通常来说有以下 2 种解决方法：

通过在总线加 LOCK# 锁的方式
在早期的 CPU 当中，是通过在总线上加 LOCK# 锁的形式来解决缓存不一致的问题。因为 CPU 和其他部件进行通信都是通过总线来进行的，如果对总线加 LOCK# 锁的话，也就是说阻塞了其他 CPU 对其他部件访问（如内存），从而使得只能有一个 CPU 能使用这个变量的内存。由于在锁住总线期间，其他 CPU 无法访问内存，导致效率低下。
通过缓存一致性协议
核心的思想是：当 CPU 写数据时，如果发现操作的变量是共享变量，即在其他 CPU 中也存在该变量的副本，会发出信号通知其他 CPU 将该变量的缓存行置为无效状态，因此当其他 CPU 需要读取这个变量时，发现自己缓存中缓存该变量的缓存行是无效的，那么它就会从内存重新读取。

如图所示：

Java 内存模型

Java 虚拟机规范试图定义一种 Java 内存模型（java memory model）来屏蔽掉各种硬件和操作系统的内存访问差异，以实现让 Java 程序在各种平台下都能达到一致的内存访问效果。

主内存与工作内存

Java 内存模型规定了：所有的变量都存储在主内存中。

每条线程都有自己的工作线程： 线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作（读取，赋值）都必须在工作内存中进行，而不能直接读写内存中的变量；不同的线程之间也无法直接访问对方工作内存中的变量。

线程间变量值的传递均需要通过主内存来完成：线程、内存、工作内存三者关系如下所示：

这里所讲的主内存，工作内存与前面讲的 Java 内存区域中的 Java 堆，栈，方法区等并不是同一个层次的内存划分，这两者基本没有关系：

如果硬要扯上关系，则：主内存主要对应于 Java 堆中的对象实例数据部分，而工作内存则对应于虚拟机栈中的部分区域。
更低层次上说：主内存就直接对应于物理硬件的内存，而为了获得更好的运行速度，虚拟机可能会让工作内存优先存储于寄存器和高速缓存中，因为程序运行时主要访问读写的是工作内存。

内存间交互操作

关于主内存与工作内存间的交互协议，即一个变量如何从主内存拷贝到工作内存，如何从工作内存同步回主内存；

Java 内存模型中定义了以下 8 种操作：

lock（锁定）：作用于主内存的变量，它把一个变量标识为一条线程独占的状态；
unlock（解锁）：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定；
read（读取）：作用于主内存的变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的 load 动作使用；
load（载入）：作用于工作内存的变量，它把 read 操作从主内存中得到的变量放入工作内存的变量副本中；
use（使用）：作用于工作内存的变量，它把工作内存中一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用到变量的值的字节码指令时将会执行这个操作；
assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作；
store（存储）：作用于工作内存的变量，它把工作内存中一个变量的值传送到主内存中，以便随后的 write 操作使用；
write（写入）：作用于主内存的变量，它把 store 操作从工作内存中得到的变量的值放入主内存的变量中；

相关操作：

把变量从主内存复制到工作内存：顺序执行 read 和 load 操作（目的地是工作内存）；
把变量从工作内存同步回主内存：顺序执行 store 和 write 操作（目的地是主内存）；
Java 内存模型只要求上述两个操作必须按顺序执行，没有保证是连续执行；即 read 和 load 之间，store 和 write之间可以插入其他指令；

Java 内存模型还规定了在执行上述8种基本操作时必须满足如下规则（rules）：

不允许 read 和 load，store 和 write 操作之一单独出现，即不允许一个变量从主内存读取了但工作内存不接受，或者从工作内存发起回写了但主内存不接受的情况出现；
不允许一个线程丢弃它的最近的 assign 操作，即变量在工作内存中改变了之后必须把该变化同步回主内存；
不允许一个线程无原因地（没有发生过任何 assign 操作）把数据从线程的工作内存同步回主内存中；
一个新变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化的变量，换句话说，对一个变量实施 use，store 操作前，必须先执行过 assign 和 load 操作；
一个变量在同一个时刻只允许一个线程对其进行 lock 操作，但 lock 操作可以被同一条线程重复执行多次，多次执行 lock 后，只有执行相同次数的 unlock 操作，变量才会被解锁；
如果对一个变量执行 lock 操作，那将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行 load 或 assign 操作初始化变量的值；
如果一个变量事先没有被 lock 操作锁定，那就不允许对它执行 unlock 操作，也不允许去 unlock 一个被其他线程锁定住的变量；
对一个变量执行 unlock 变量前，必须先把此变量同步回主内存中（执行 store，write操作）；

volatile型变量的特殊规则

当一个变量定义为 volatile 后，它具备两种特性：

保证此变量对所有线程的可见性，这里的可见性指：当一条线程修改了这个变量的值，新值对于其他线程来说是可以立即得知的。而普通变量做不到这一点，其在线程间传递需要通过主内存来完成；
对于 volatile 变量的可见性，有一些误解： volatile 变量对所有线程都是可见的，对 volatile 变量所有的写操作都能立刻反应到其他线程中，即，volatile 变量在各个线程中是一致的，所有基于 volatile 变量的运算在并发下是安全的；上述语句中的错误在于并不能得出“基于 volatile 变量的运算在并发下是安全的”这个结论。

虽然 volatile 变量在各个线程的工作内存中不存在一致性问题，但 Java 里面的运算并非原子操作，导致 volatile 变量的运算在并发下一样是不安全的。

由于 volatile 变量只能保证可见性，在不符合以下两条规则的运算场景中，我们仍然要通过加锁来保证原子性：

运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值；
变量不需要与其他的状态变量共同参与不变约束；

使用 volatile 变量的第二个语义是禁止指令重排序优化：普通变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。因为在一个线程的方法执行过程中无法感知到这点，这也就是 Java 内存模型中描述的所谓的 “线程内表现为串行的语义”；

// 指令重排序演示（伪代码）  
    public void instruct_reorder() {  
        Map configOptions;  
        char[] configText;  
        //  此变量必须为 volatile  
        volatile boolean initialized = false;  
          
        // 假设以下代码在线程A 中执行  
        // 模拟读取配置信息，当读取完成后将 initialized 设置为true 已通知其他线程配置可用  
        configOptions = new HashMap();  
        configText = readConfigFile(filename);  
        processConfigOptions(configText, configOptions);  
        initialized = true;  
          
        // 假设以下代码在线程B 中执行  
        // 等待initialized 为true，代表线程A 已经把配置信息初始化完成  
        while(!initialized) {  
            sleep();  
        }  
        // 使用线程A 中初始化好的配置信息  
        do_sth_with_config();  
    }

如果定义 initialized 变量没有使用 volatile 修饰：就可能会由于指令重排序的优化，导致位于线程A 中最后一句代码 initialized=true 被提前执行；这样在线程 B 中使用配置信息的代码就可能出现错误，而 volatile 关键字则可以避免此类情况的发生；

volatile 的特殊规则：

要求在工作内存中，每次使用 volatile 型变量时，必须先从主内存刷新最新的值，用于保证能看见其他线程对 volatile 型变量所做的修改后的值。
要求在工作内存中，每次修改 volatile 型变量后必须同步到主内存中，用于保证其他线程可以看到自己对该变量所做的修改。
要求 volatile 修饰的变量不会被指令重排序优化，保证代码的执行顺序与程序的顺序相同。

long 和 double 型变量的特殊规则

Java 内存模型要求 lock， unlock， read， load， assign， use，store，write 这 8 个操作都具有原子性： 但对于64位的数据类型（long和double），在模型中特别定义了一条相对宽松的规定：允许虚拟机将没有被 volatile 修饰的64位数据的读写操作划分为两次32位的操作来进行，即允许虚拟机实现选择可以不保证64位数据类型的 load，store，read 和 write 这4个操作的原子性，这点就是所谓的 long 和 double 的非原子性协定；

这项宽松的规定所导致的problem：如果有多个线程共享一个并未声明为 volatile 的 long 或 double 类型的变量，并且同时对它们进行读取和修改操作，那么某些线程可能会读取到一个既非原值，也不是其他线程修改值的代表了半个变量的数值；

不过这种读取到的“半个变量”的case非常罕见：因为 Java 内存模型虽然允许虚拟机不把 long 和 double 变量的读写实现成原子操作，但允许虚拟机选择把这些操作实现为具有原子性的操作，而且还强烈建议虚拟机这样实现；

原子性，可见性与有序性

Java 内存模型是围绕着在并发过程中如何处理原子性，可见性和有序性这3个特征来建立的

原子性

由于 Java 内存模型来直接保证的原子性变量操作包括 read，load，assign，use，store 和write，我们大致认为基本数据类型的访问读写数据是具备原子性的。

同步块——synchronized关键字：如果应用场景需要一个更大范围的原子性保证，Java 内存模型还提供了 lock 和 unlock 操作来满足这些需求，尽管虚拟机没有把 lock 和 unlock 操作直接开放给用户使用，但是却提供了更高层次的字节码指令 monitorenter 和 monitorexit 来隐式地使用这两个操作；这两个字节码指令反映到 java 代码中就是同步块——synchronized关键字：因此在synchronized 块之间的操作也具备原子性；

可见性

可见性指当一个线程修改了共享变量的值，其他线程能够立即得知这个修改。

Java 内存模型是通过在变量修改后将新值同步回主内存，在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现可见性的，无论是普通变量还是 volatile 变量都是如此；
普通变量与 volatile 变量的区别是：volatile 的特殊规则保证了新值能立即同步到主内存，以及每次使用前立即从主内存刷新；所以 volatile 保证了多线程操作时变量的可见性，普通变量则不能保证这一点；

Java 还有两个关键字实现可见性： synchronized 和 final：

同步块的可见性： 是由对一个变量执行 unlock 操作前，必须先把此变量同步回主内存中；
final 关键字的可见性：被 final 修饰的字段在构造器中一旦初始化完成，并且构造器没有把this 的引用传递出去（this 引用逃逸是一件非常危险的事，其他线程有可能通过这个引用访问到“初始化了一半”的对象），那在其他线程中就能看见 final 字段的值。

有序性

Java 程序中天然的有序性总结为一句话：如果在本线程内观察，所有的操作都是有序的；如果在一个线程中观察另一个线程，所有的操作都是无序的。前半句是指：线程内表现为串行的语义，后半句是指：指令重排序现象和工作内存与主内存同步延迟现象；

volatile 和 synchronized 关键字保证了线程间操作的有序性：volatile 关键字本身就包含了禁止指令重排序的语义，而 synchronized 则是由一个变量在同一时刻只允许一条线程对其进行 lock 操作这条规则获得的，这条规则决定了持有同一个锁的两个同步块只能串行地进入；

先行发生原则

先行发生原则定义：先行发生是 Java 内存模型中定义的两项操作之间的偏序关系，如果说操作 A 先行发生于操作 B，其实就是说在发生操作 B 之前，操作 A 产生的影响能被操作 B 观察到，影响包括修改了内存中共享变量的值，发送了消息，调用了方法等。

下面是 Java 内存模型下一些天然的先行发生关系，这些先行发生关系无须任何同步器协助就已经存在，可以在编码中直接使用：

程序次序规则：在一个线程内，按照程序代码顺序，书写在前面的操作先行发生于书写在后面的操作；准确地说，应该是控制流顺序；
管程锁定规则：一个 unlock 操作先行发生于后面对同一个锁的 lock 操作；这里必须强调的是同一个锁，而后面是指时间上的先后顺序；
volatile变量规则：对一个 volatile 变量的写操作先行发生于后面对这个变量的读操作，这里的后面是指时间上的先后顺序；
线程启动规则：Thread 对象的 start() 方法先行发生于此线程的每一个动作；
线程终止规则：线程中的所有操作都先行发生于对此线程的终止检测，可以通过 Thread.join() 方法结束，Thread.isAlive() 的返回值等手段检测到线程已经终止运行；
线程中断规则：对线程 interrupt() 方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过 Thread.interrrupted() 方法检测到是否有中断发生；
对象终结规则：一个对象的初始化完成先行发生于它的 finalize() 方法的开始；
传递性：如果操作 A 先行发生于操作 B，操作 B 先行发生于操作 C，那就可以得出操作 A 先行发生于操作 C 的结论；

Java 与线程

线程的实现

线程是比进程更轻量级的调度执行单位： 线程的引入，可以把一个进程的资源分配和执行调度分开，各个线程既可以共享进程资源（内存地址，文件 IO等），又可以独立调度（线程是 CPU 调度的基本单位）；
线程实现的3种方式：

使用内核线程实现
使用用户线程实现
使用用户线程加轻量级进程混合实现

使用内核线程实现

内核线程（KLT，Kernel-Level Thread）：就是直接由操作系统内核（下称内核）支持的线程，这种线程由内核来完成线程切换，内核通过操纵调度器对线程进行调度，并负责将线程的任务映射到各个处理器上。

程序一般不会直接去使用内核线程，而是去使用内核线程的一种高级接口——轻量级进程（Light Weight Process, LWP）：轻量级进程就是我们通常意义上讲的线程，由于每个轻量级线程都由一个内核线程支持，因此只有先支持内核线程，才能有轻量级进程。这种轻量级进程与内核线程间1:1 的关系称为一对一的线程模型，如下图所示：

轻量级进程有局限性：

由于是基于内核线程实现的，所以各种线程操作，如创建，析构及同步，都需要进行系统调用，而系统调用的代价相对较高，需要在用户态和内核态中来回切换；
每个轻量级进程都需要有一个内存线程的支持，因此轻量级进程要消耗一定的内核资源（如内核线程的栈空间），因此一个系统支持轻量级进程的数量是有限的；

使用用户线程实现

完全建立在用户空间的线程库上，系统内核不能感知线程存在，不需内核帮助和切换到内核态，因此操作是非常快熟且低消耗的。进程和用户线程之间1：N的关系称为一对多的线程模型。劣势也在于没有系统内核的支持，所有的线程操作都需要用户程序自己处理。已被放弃使用。

使用用户线程加轻量级进程混合实现

在该实现方式下，既存在用户线程，也存在轻量级进程；用户线程还是完全建立在用户空间中：因此用户线程的创建，切换，析构等操作依然廉价，并且可以支持大规模的用户线程并发；操作系统提供支持的轻量级进程则作为用户线程和内核线程之间的桥梁：这样可以使用内核提供的线程调度功能及处理器映射，并且用户线程的系统调用要通过轻量级线程来完成，大大降低了整个进程被完全阻塞的风险；
在这种混合模式中：用户线程与轻量级进程的数量比是不定的，即为 N：M 的关系，如下图所示，这种就是多对多的线程模型；

Java 线程调度

线程调度定义：是指系统为线程分配处理器使用权的过程，主要调度方式有：协同式线程调度和抢占式线程调度；

协同式线程调度

线程的执行时间由线程本身来控制，线程把自己的工作执行完以后，要主动通知系统切换到另外一个线程上；
优点：
实现简单，而且由于线程要把自己的事情干完后才会进行线程切换，切换操作读线程自己是可知的，所以没有什么线程同步的问题；
缺点：
线程执行时间不可控制，甚至如果一个线程编写有问题，一直不告诉系统进行线程切换，那么程序就会一直阻塞在那里；

抢占式线程调度

每个线程将由系统来分配执行时间，线程的切换不由线程本身来决定；Java使用的方式就是抢占式线程调度方式

可以设置线程优先级的方式建议系统给某些线程多分配一点执行时间